home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group96a.txt
/
000187_icon-group-sender _Thu Aug 15 07:03:48 1996.msg
< prev
next >
Wrap
Internet Message Format
|
1996-09-05
|
2KB
Received: by cheltenham.cs.arizona.edu; Fri, 16 Aug 1996 12:45:47 MST
Date: Thu, 15 Aug 1996 07:03:48 -0500
Message-Id: <199608151203.HAA22106@ns1.computek.net>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: gep2@computek.net
Subject: Re: Problem with graphics
To: rjhare@tattoo.ed.ac.uk, icon-group@cs.arizona.edu
X-Mailer: SPRY Mail Version: 04.00.06.17
Errors-To: icon-group-errors@cs.arizona.edu
>The 'obvious' way to do this, and the way I think I am going to have to go is
to use 2 windows, one of them off screen wityh the grid drawn on the on screen
window. Every time I draw to the on screen window, I draw to the off screen
window, and when I save, I save the off screen window thus avoiding saving the
grid. It's a pain because I have 2 lines of drawing code where before I had
one. However...
A lot clearly depends on how much you draw, and how much memory a secondary
window will require, versus how many times you actually do save the window to
disk.
One approach would be to maintain a list containing all the graphics calls (and
their parameters) you have made since erasing or creating a graphics window.
Then, before saving it, you can run down the list and essentially recreate the
window (or do any desired subset of the calls that created it... this is how
AutoCAD and other software handle their "layering" stuff I think). If you build
a set of suitable graphics front-end routines, this could be transparent to the
calling program (and you'd not have to duplicate your calls in-line).
Gordon Peterson
http://www.computek.net/public/gep2/